<!-- markdownlint-configure-file { "no-trailing-punctuation": 0 } -->

import FlavorizedCodeBlock from '@site/src/components/FlavorizedCodeBlock';

Check the **build** and **binaryPath** attributes for the `android.debug` and `android.release` Detox configs:

```js title=".detoxrc.js"
module.exports = {
  apps: {
    'android.debug': {
      type: 'android.apk',
      // highlight-start
      build: 'cd android && ./gradlew assembleDebug assembleAndroidTest -DtestBuildType=debug',
      binaryPath: 'android/app/build/outputs/apk/debug/app-debug.apk'
      // highlight-end
    },
    'android.release': {
      type: 'android.apk',
      // highlight-start
      build: 'cd android && ./gradlew assembleRelease assembleAndroidTest -DtestBuildType=release',
      binaryPath: 'android/app/build/outputs/apk/release/app-release.apk'
      // highlight-end
    },
    // ...
  },
  // ...
};
```

If you have a typical React Native project, these values should already be sufficient and correct.

#### testBinaryPath

In Android automation testing, there are in fact 2 app binaries involved:
1. The _app_ APK, containing your app's code.
2. The _test_ APK, containing _test_ code. That includes Detox's native code, Espresso and more.

In some projects, it might make sense for the test APK to be generated over a separate flow, through which is may end up
being put it some custom,
[non-default path](https://stackoverflow.com/questions/43670463/where-is-the-test-apk-located-in-android-project).
One such example is an optimization where the test APK is prebuilt once and used across multiple app variations. This is
a place where the `testBinaryPath` attribute can come to the rescue; It can be applied in order to set the custom path
to the test APK explicitly:

```js title=".detoxrc.js"
module.exports = {
  apps: {
    'android.debug': {
      type: 'android.apk',
      build: 'cd android && ./gradlew assembleDebug assembleAndroidTest -DtestBuildType=debug',
      binaryPath: 'android/app/build/outputs/apk/debug/app-debug.apk',
      // highlight-start
      testBinaryPath: 'custom/path/to/app-debug-androidTest.apk'
      // highlight-end
    },
    'android.release': {
      type: 'android.apk',
      binaryPath: 'android/app/build/outputs/apk/release/app-release.apk',
      build: 'cd android && ./gradlew assembleRelease assembleAndroidTest -DtestBuildType=release',
      // highlight-start
      testBinaryPath: 'custom/path/to/app-release-androidTest.apk'
      // highlight-end
    },
    // ...
  },
  // ...
};
```

:::info Note

In the common case, the `testBinaryPath` attributes is not explicitly required, simply because Detox knows
how to locate it in one of the default paths automatically.

:::

#### Product flavors

On even more advanced use cases, apps may have additional, custom [`productFlavors`](https://developer.android.com/studio/build/build-variants#product-flavors)
(for example, `driver` and `passenger` flavors of a taxi application). In this case, you should rewrite your apps config,
for both **debug** and **release** configurations, according to those flavors, e.g.:

<FlavorizedCodeBlock
  language="diff"
  header={'   apps: {\n'}
  flavors={['Driver', 'Passenger']}
>
  {(flavor) => `\
     '${flavor.toLowerCase()}.android.debug': {
       type: 'android.apk',
-      binaryPath: 'android/app/build/outputs/apk/debug/app-debug.apk',
+      binaryPath: 'android/app/build/outputs/apk/${flavor.toLowerCase()}/debug/app-${flavor.toLowerCase()}-debug.apk',
-      build: 'cd android && ./gradlew assembleDebug assembleAndroidTest -DtestBuildType=debug',
+      build: 'cd android && ./gradlew assemble${flavor}Debug assemble${flavor}DebugAndroidTest -DtestBuildType=debug',
     },`}
</FlavorizedCodeBlock>
